Field of the Invention
This invention relates generally to a system and method for resetting a controller in response to a controller area network (CAN) bus off state and, more particularly, to a system and method for resetting an electronic control unit (ECU) on a vehicle in response to a CAN controller bus off state that includes differentiating between internal ECU faults and random external disturbances.
Discussion of the Related Art
Most modern vehicles include many electronic control units (ECUs) or controllers that control the operation of various vehicle systems, such as power train, climate control system, infotainment system, body systems, chassis systems, etc. Such controllers and ECUs require special purpose and designed software that allow them to perform their control functions. Many or all of the ECUs associated with a particular vehicle system are typically part of a distributed controller area (CAN) network that employs a CAN bus in electrical communication with the several ECUs that allows for the transmission of messages between the ECUs. Each ECU includes a hardware circuit known as a CAN controller that controls the transmission of messages onto the CAN bus and the receipt of messages from the CAN bus. The CAN controller provides signals to a host application layer on the ECU that includes the software that operates the ECU for the particular purpose.
Message errors occur when the CAN controller determines that a message has an improper header format or other improper configuration. Errors can occur as a result of random external disturbances, such as EMI pulses, or internal controller faults. If the CAN controller in an ECU receives a message from the CAN bus and determines that the message has an error, that CAN controller can corrupt the message so that it is not usable by other ECUs coupled to the bus. If a faulty CAN controller improperly corrupts a message because it thinks it has an error when it does not, then the other ECUs in the CAN network cannot use the message when they should be able to.
Each CAN controller in a CAN network typically operates in one of three states, namely, an error active state, an error passive state and a bus off state. When a CAN controller is in its active mode or error active state and providing messages to and receiving messages from the CAN bus, errors of the type as discussed above may occur where the transmission of data to or the reception of data from the bus has failed. The CAN controller may send active error flags onto the bus to corrupt messages on the bus as mentioned above. The CAN controller accumulates the errors over time and when the number of errors for the reception of messages, as accumulated by a receive error counter (REC) in the CAN controller, or when the number of errors for the transmission of messages, as accumulated by a transmission error counter (TEC) in the CAN controller, reaches a predetermined value, such as 127, the CAN controller enters the error passive state, where it cannot corrupt messages on the bus. During the error passive state, the TEC will continue to accumulate transmission errors and once a second count value has been reached, such as 255, the CAN controller enters a bus off state and is disconnected from the CAN bus. Thus, by putting the CAN controller in the error passive state once is has accumulated a predetermined number of errors, the CAN controller is prevented from corrupting messages that would otherwise be valid for the other ECUs in the network, and then when the transmission of errors reaches another predetermined value, the CAN controller is prevented from transmitting error messages onto the bus that would otherwise be acted on by other ECUs in the network.
The CAN controller notifies the application layer when the bus off state occurs. The application layer is programmed with a certain protocol that allows it to reset the CAN controller after a bus off state occurs so that the CAN controller can again become active to send and transmit messages on the CAN bus. Thus, the CAN controller remains in the bus off state until the application layer initiates the reset of the CAN controller to the error active state. Different CAN networks employ different types of bus off reset policies to determine how and when the application layer resets the CAN controller.
In one known bus off reset policy, referred to as an auto-reset policy, the application layer initiates the reset of the CAN controller immediately after the CAN controller enters the bus off state and the CAN controller returns to the error active state after it receives a predetermined number of recessive bits a predetermined number of times, such as 128 recessive bits 11 times. However, if the CAN controller itself is faulty and the application layer immediately resets the CAN controller, the CAN controller would repeatedly interrupt the normal vehicle control.
In another known bus off reset policy, referred to as a wait-then-reset policy, the application layer will wait some predetermined period of time after the bus off state occurs to give the CAN controller time to recover from the fault condition. However, as mentioned, there are certain CAN controller error conditions caused by external interferences, such as electromagnetic radiation, that are random and periodic and do not last for very long. If the bus off reset policy is to wait and then reset the CAN controller to the error active state, and the result of the error is an external disturbance, then the CAN controller will be offline for some period of time where the interference probably is still not causing problems. During this time, the particular CAN controller will not be able to put messages onto the bus, possibly effecting vehicle operation and performance. Therefore, a CAN controller that is waiting for a message from another CAN controller that is in the wait period for the bus off reset policy may set a diagnostic trouble code (DTC) that indicates that the CAN controller is not available to send messages.
In another known bus off reset policy, referred to as a frequency-limited-reset policy, it is required that the time between any two subsequent resets must be larger than a predetermined time interval. For this case, if a second bus off state occurs after the predetermined time interval from the reset of the first bus off state then the application layer immediately resets the CAN controller. However, for a faulty controller, too small of a time interval between the resets would result in the immediate reset of the CAN controller for a bus off state and the CAN controller would have no time to recover from the fault resulting in continuous interference of the normal communications on the bus, and too long of a time interval would result in unnecessary interruption of the CAN controller when not being connected to the bus. Analysis has shown that no appropriate time interval between bus off state and reset can satisfactorily address the above situations.